An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

I submitted my first public build (iOS 1.0) on July 30th for my game, Golfer's Pair-A-Dice (Apple ID: 6789222313) and it has been in "Waiting for Review" with no movement since then. I read that 24-48 hours is typical, but could take longer for first builds, but it seems like it hasn't even begun to be reviewed which is frustrating. Has anyone experienced similar wait times in the queue and had any success getting their app reviewed? I was hoping to launch on App Store and Google Play Store at same time and Google approved the app in 2 days so it has just been waiting for me to push, which I am waiting on Apple to approve so I can push both simultaneously.

Hello, My app Jewel Coloring Go! (App ID: 6785241915) appears to be stuck in the App Review process, and I would like to check whether there may be an issue with this submission. The current version was originally planned for release on July 31, 2026. However, today is Auguse 9, 2026, and the app is still in "Waiting for Review." Current status: Waiting for Review No messages in Resolution Center No requests for additional information We have also submitted multiple Support inquiries but have not received any response so far. This version is particularly important to our team, as it is tied to a planned release schedule and user acquisition activities that had already been prepared in advance. Given the unusually long delay, we are unsure whether the submission is proceeding normally or if there may be an issue requiring attention. If an Apple staff member could help check the status of this submission, it would be greatly appreciated. Thank you for your time and assistance.

Hi everyone, Not sure if this is a known App Store Connect bug but hoping either someone here has a workaround, or an Apple engineer can help push this along. Background: this is my first In-App Purchase submission for my app. My original binary was submitted without the IAP attached (my mistake, first time doing this), so the app was rejected under Guideline 2.1(b) for referencing a paid feature whose IAP wasn't submitted for review. Since then: The IAP (non-consumable, one-time purchase) is fully configured with a review screenshot and notes, and shows status "Ready for Review" after submitting via "Add for Review" My app version is in a rejected state with an "Update Review" button available The problem: I can't get these two linked together anywhere in the UI. Clicking "Update Review" on the version page resubmits it, but never shows any option to attach the IAP Clicking "Add for Review" from the IAP page opens a Draft Submission, but that draft says "Unable to Submit for Review: To submit your items for review, add an app version for the selected platform," with no version selector anywhere in that panel Tried hard refresh, incognito, different browsers, starting a fresh draft submission. Same result every time. Result: resubmitted the app, got the exact same 2.1(b) rejection again, confirming the IAP genuinely never made it into the review package despite showing as correctly configured on my end. I've seen a few other threads describing what sounds like the exact same issue, where the "In-App Purchases and Subscriptions" section disappears from the version page after a first rejection, and the fix ended up requiring an Apple support agent to manually push the IAP status forward on the backend, without needing another binary. Has anyone found a way to trigger this from the developer side, or is direct support/engineering intervention really the only path? Already have a case open with Apple Developer Support as well, happy to share the Case ID via DM if that helps someone from Apple locate it faster. Thanks in advance for any pointers.

My app was rejected under Guideline 2.3 (Accurate Metadata) with the standard text saying the UIRequiredDeviceCapabilities key is set up so that the app will not install on the review device. The review device was an iPad Air 11-inch (M3) on iPadOS 26.6. I inspected the Info.plist inside the exact archive that was uploaded. Everything relevant: UIRequiredDeviceCapabilities = (arm64) UIDeviceFamily = (1, 2) MinimumOSVersion = 18.0 Binary architectures = arm64 Built with Xcode 26.6, iOS 26.5 SDK An iPad Air 11-inch (M3) is arm64, is device family 2, and runs an OS far above 18.0, so as far as I can tell nothing in that plist can prevent installation. arm64 is the value Xcode injects automatically, and I have never declared the key myself. What I have already checked: There is no UIRequiredDeviceCapabilities in my source Info.plist and no INFOPLIST_KEY build setting for it. The value is injected at build time. I added the key to my own Info.plist as an empty array to try to override the injection. Xcode still writes (arm64) into the built plist, so I cannot remove it. I built the same Release configuration and installed it on an iPad Air 11-inch (M3) simulator running iPadOS 26.2, the highest iPadOS available to me. It installs and launches with no error. There are no app extensions. One target, TARGETED_DEVICE_FAMILY = "1,2". My questions: Is arm64 in UIRequiredDeviceCapabilities known to trigger this rejection on iPadOS 26 review devices, or is something else being reported under this template? Is there any supported way to suppress the value Xcode injects, or will the array always contain arm64 for an arm64-only binary? If the installation failure was real but caused by something other than this key, what else produces an install failure that App Review would attribute to UIRequiredDeviceCapabilities? Context for why I am asking here and not only in App Store Connect: the build sat in Waiting for Review for about a week and a half, I used my expedited request, it was rejected on this, I replied in Resolution Center with the plist contents and received no answer, and the resubmission is back in Waiting for Review. I am not asking anyone here to change a review outcome. I am trying to find out whether this is a known issue with the key so I can stop guessing. Any pointer would be appreciated.

Hi, re-iterating the previous post regarding the approval wait. It's now been past 48 hours since my new request for the new build, and the app still has not been approved. Would really appreciate the prompt review to avoid any further delays. Thanks in advance!

App: AI RunCoach — App ID 6782097197, bundle ID com.airuncoach.app, Team ID 4N3X74Y2LF When adding a new build to our External Testing group, TestFlight shows: "Before you can use TestFlight to distribute beta builds of your app, you must renew your Apple Developer Program membership." Our membership is not expired: the Membership Details page shows renewal date 20 June 2027, auto-renew ON, and the €99 fee already paid. We've also checked Agreements, Tax, and Banking — nothing shows as pending or requiring action anywhere. In the meantime, our app has been stuck in "In Review" status since August 3, and TestFlight installations also seem to be blocked. A request for an expedited review produced no result, and a request for a phone consultation did not lead to any contact either. Did anyone else experience this, and could someone advise on how to contact Apple about this? Thanks in advance for any pointers.

This is my first app and my first App Store submission, after a substantial amount of work preparing Rendr Markdown for release and making sure that everything was ready for Apple’s review process. I submitted Rendr Markdown 3.3.10 for macOS on August 13, 2026 at approximately 04:00 CEST. More than six days later, it is still in Waiting for Review. As a new Apple developer, I have to admit that I am surprised by this experience, particularly by the lack of any indication of what is causing the delay or when the submission might be reviewed. I previously spoke with Apple Developer Support regarding another App Store Connect matter. During that call, the representative also checked the app submission and confirmed that it appeared to be correctly submitted and in the review queue. As the delay continued, I contacted App Review through the App Review Status support form. I have not received a response or any indication that the case is being investigated. There have been no status changes, review messages, rejections, or requests for additional information. I therefore do not know whether this is simply an unusually long review queue or whether the submission requires intervention from Apple. Could someone from App Review please check whether this submission is progressing normally, or escalate the existing support case if necessary? App: Rendr Markdown Platform: macOS Version: 3.3.10 Apple ID: 6799048174 Submission ID: 020fe5c8-7db6-4432-969f-bb0a49d1efdc Support case: 20000140663217 Thank you.

Hello Apple Developer Community and App Review Team, I received a Pending Termination Notice on May 29, 2026, for my account (Developer: Bushra Malik) related to Section 3.2(f), regarding app submissions for Dress Up Fashion: Styling Game. I submitted a formal appeal 10 days ago but have not yet received a response or case number confirmation. I want to provide brief context: Our original Clothing Store Simulator received repeated rejections. Rather than continuing to resubmit the same app, we made the decision to build a completely new game from scratch — new code, new assets, new UI, and a fully revised App Store listing. Nothing from the original submission was carried forward. This was a deliberate good faith effort to achieve compliance, not an attempt to evade review. We also believe an older binary may have been reviewed rather than our latest build — a technical issue we have experienced previously on this account. Our account has 4+ years of publishing history and 25+ live games currently on the App Store. Not a single other app is in rejection or under any violation. We have never engaged in subscription scams, fake reviews, bait-and-switch tactics, or any of the fraudulent conduct described in the termination notice. I am respectfully requesting: Confirmation that my appeal is actively under review A status update or case reference number Any additional information Apple needs from our side We are fully cooperative and have all source code, assets, and submission history available immediately upon request. Thank you sincerely for your time. Bushra Malik Apple Developer Account: Bushra Malik

Repeated Guideline 4.1(a) rejection for my game Hello, I’m looking for some advice regarding a repeated App Review rejection. My game is Pet Shop Owner Simulator. It was originally developed and published by me under Tri Creations on Google Play. I’m now submitting it to the App Store, but it has been rejected multiple times under Guideline 4.1(a) – Design – Copycats. The latest rejection states: “The app’s description, name, and icons includes references to Pet Shop Owner Simulator 3D.” The confusing part is that Pet Shop Owner Simulator 3D is the name of my own Android game. I have already explained this to App Review and provided documentation showing my ownership, but I continue to receive the same rejection. Could someone please advise how I can clarify this with App Review? In particular, I would like to understand whether Apple is referring to a specific third-party app or developer, or if there is something specific in my App Store metadata that I should change. Thank you.

Hi everyone, I’m looking for advice from developers who may have experienced a similar App Review situation. Our app, ASK VPN (Apple ID: 679*****), has been rejected multiple times, and I’m struggling to understand exactly what Apple is detecting. Initially, the app was rejected under Guideline 4.3(a) - Design - Spam. Apple first stated that the app shared a similar binary, metadata, and/or concept with apps previously submitted by a terminated Apple Developer Program account. After we asked for clarification, Apple later stated that the app shared a similar binary, metadata, and/or concept with apps submitted by other developers, with only minor differences. To clarify an important point: we did not purchase this VPN source code from another developer, and we did not use a commercial VPN template, cloned project, or repackaged source code. ASK VPN was developed specifically for this project. I defined the product strategy, required functionality, user flow, and design direction myself, and used Codex AI as a development assistant to help implement the application. The codebase was created for ASK VPN rather than acquired from another developer or reused from an existing App Store application. Because of that, the earlier Guideline 4.3(a) rejection mentioning similarity to apps associated with other developers, including a terminated developer account, is particularly confusing to us. After the earlier rejection, we carefully reviewed and updated the application and added or improved product-specific functionality, including: Native iOS VPN implementation using Network Extension / Packet Tunnel ASK VPN account and profile integration Account status and expiry information First-use onboarding Terms and Conditions acceptance Privacy and VPN disclosure screens English and Myanmar localization In-app support and guided help Support diagnostic / Profile ID functionality Secure handling and redaction of sensitive VPN configuration data Updated app-specific UI and functionality We explained these changes to App Review and repeatedly asked which specific part was considered similar — source code, VPN implementation, framework, metadata, screenshots, assets, certificates, signing history, bundle identifier, backend behavior, or app functionality — but we did not receive a specific technical explanation. Now, on our latest submission, the rejection has changed to: Guideline 5.6 - Developer Code of Conduct Apple states: “The app contains features that appear to have been intentionally hidden during the review process.” This is especially confusing and concerning because we are not intentionally hiding any features from App Review. Another thing I have noticed is that the app enters “In Review” and then gets rejected very quickly, sometimes almost immediately. This has happened repeatedly. Because the rejection happens so quickly, I am wondering whether an automated or internal detection system may be flagging something related to the binary, code structure, Network Extension, account association, signing history, backend behavior, configuration, or another technical characteristic. At this point, we are willing to provide Apple with the complete source code of the application for technical review. We are also willing to provide: Complete iOS source code Network Extension / Packet Tunnel implementation Backend and API implementation Server-side configuration relevant to app behavior Feature flags and remote configuration Environment-specific configuration Authentication and account logic Source-control history Design and implementation records Complete feature documentation Test accounts and credentials Any other technical information Apple may require We would also be willing to provide access to a private source-code repository if Apple has an approved secure method for doing so. We are not looking for a way around App Review. We genuinely want to understand the exact issue, correct it properly, and fully comply with the App Store Review Guidelines. I would really appreciate advice from anyone who has experienced something similar. In particular: What can cause Apple to associate a newly developed app with apps from a terminated Developer Program account? Can common Network Extension / Packet Tunnel implementation patterns trigger similarity detection? Can AI-assisted code, standard iOS architecture, common libraries, or generated implementation patterns contribute to binary or source-code similarity? What can cause Apple to believe functionality is intentionally hidden during review? Could API responses, server-side behavior, feature flags, account states, device region, IP address, or review-environment differences cause this? Could signing history, certificates, bundle history, provisioning, or backend infrastructure create an association with another developer? Is there a way to request a deeper technical investigation or provide Apple with the complete source code? What is the best escalation path when repeated App Review replies do not identify the specific feature, code path, or behavior causing the rejection? Has anyone experienced a similar progression from Guideline 4.3(a) → Guideline 5.6? I’m honestly very discouraged after going through repeated rejections without being able to identify the root cause, but I want to resolve this correctly rather than keep making speculative changes and resubmitting. Any technical guidance or experience from developers who have dealt with a similar case would be greatly appreciated. Thank you.

Hi everyone, Running into not really sure if it's App Store Connect bug but hoping either someone here has a workaround, or an Apple engineer can help push this along. Background: this is my first In-App Purchase submission for my app. My original binary was submitted without the IAP attached (my mistake, first time doing this), so the app was rejected under Guideline 2.1(b) for referencing a paid feature whose IAP wasn't submitted for review. Since then: The IAP (non-consumable, one-time purchase) is fully configured with a review screenshot and notes, and shows status "Ready for Review" after submitting via "Add for Review" My app version is in a rejected state with an "Update Review" button available The problem: I can't get these two linked together anywhere in the UI. Clicking "Update Review" on the version page resubmits it, but never shows any option to attach the IAP Clicking "Add for Review" from the IAP page opens a Draft Submission, but that draft says "Unable to Submit for Review: To submit your items for review, add an app version for the selected platform," with no version selector anywhere in that panel Tried hard refresh, incognito, different browsers, starting a fresh draft submission. Same result every time. Result: resubmitted the app, got the exact same 2.1(b) rejection again, confirming the IAP genuinely never made it into the review package despite showing as correctly configured on my end. I've seen a few other threads describing what sounds like the exact same issue, where the "In-App Purchases and Subscriptions" section disappears from the version page after a first rejection, and the fix ended up requiring an Apple support agent to manually push the IAP status forward on the backend, without needing another binary. Has anyone found a way to trigger this from the developer side, or is direct support/engineering intervention really the only path? Already have a case open with Apple Developer Support as well, happy to share the Case ID via DM if that helps someone from Apple locate it faster. Thanks in advance for any pointers.

Hello, Our app has been in "Waiting for Review" since August 11, 2026, with no status change and no messages in App Store Connect. App Name: Voxen AI Apple ID: 6790147633 Version: 1.0.0 (139) Submission ID: bd9db3ca-72f9-46ad-ace5-6fdfc873e59f Date Submitted: Aug 11, 2026 at 9:55 AM Could someone from App Review check whether this submission is stuck in the queue, or let us know if any action is needed on our side? Thank you.

Hi, I’m looking for technical advice on a repeated App Review issue with our app, ASK VPN (Apple ID: 67...). ASK VPN is a simple consumer VPN app for iOS. It uses Apple’s Network Extension / Packet Tunnel APIs. Users sign in, retrieve their assigned VPN profile, view account status/expiry, and connect through a single main connection flow. The app was built specifically for this project. We did not purchase or reuse a VPN template or source code from another developer. I designed the product flow and UI, and used Codex AI as a development assistant. Our rejection history is: Guideline 4.3(a): Apple said the app had a similar binary, metadata, and/or concept to apps submitted by other developers, including one associated with a terminated Developer Program account. We reviewed the app, changed product-specific functionality and UI, added onboarding, privacy/VPN disclosures, localization, support features, diagnostics, and clarified the implementation to App Review. The latest rejection is now Guideline 5.6, stating that the app contains features that appear to have been intentionally hidden during review. We do not intentionally hide any functionality from App Review, and we have not been told which specific feature or behavior is considered hidden. One thing that concerns me is that the app often moves to In Review and is rejected very quickly. My main questions are: What technical factors can cause a custom-built VPN app using Network Extension / Packet Tunnel to be associated with another developer’s app or terminated account? What kinds of implementation or server-side behavior commonly lead App Review to conclude that functionality is being intentionally hidden? We are willing to provide Apple with complete source code, backend/API details, test accounts, and configuration if there is a secure review path for that. I would appreciate advice from anyone who has seen a similar 4.3(a) → 5.6 progression. Thank you.

Hello everyone, I'm looking for some advice on how to handle an unusually long app review delay. I submitted my iOS app (Pressie Pro Express) for review on Aug 5, 2026, and it has been stuck ever since. I reached out to Apple Developer Support via the contact form on August 14th to ask for a status update, but I didn't receive a reply. I sent a follow-up message today (August 18th) and am still waiting to hear back. Has anyone else experienced significant review delays or unresponsiveness from support recently? Are there any alternative channels or best practices for escalating a review that seems to be completely stuck? Any insights or advice would be greatly appreciated! Thanks, Gisha

Hi, just want to make sure that my app is approved within the 48-hour period. It's nearing the tail end of it, and I would like to confirm that the app is good to go after a few iterations with App Review team and avoid further delays like before. Thanks!

It’s not only a normal review it’s an expedited review . We’re literally desperate to get this app approved yet it’s literally been a week to review the app . What do you do ? It says 90% of apps get reviewed in a day so how can we be waiting a week ? this is so horrible

After waiting on the phone for 3 hours, a rep answered and claimed headset issues and then just hung up and hasn’t bothered to call back. Not sure what sort of service I can expect here bust can anyone tell me why App Reviews take so long? They claim they are completed in 24-48 hours. It’s been nearly a week and nothing… Any help here will be greatly appreciated.

Hello App review Team, Our app has been submitted for up to a week now. Submission id - 8b32ad4d-9912-4f25-837c-13b15323a258. Kindly review. Thank you

Hi all, Like others my app submission has been stuck in “waiting for review” for weeks. I know initial app reviews take longer than updates, but this has been delayed far too long and makes me concerned about repeating the process in the future. I submitted this app for review back on Feb 10. It was initially rejected for a minor issue, which I resolved and resubmitted the same day. After that, the build remained in “Waiting for Review” for about two weeks with no further communication. At that point I canceled the submission and resubmitted the build, thinking it may have been stuck in the queue (I now know not to do this next time). Unfortunately the new submission has also been waiting for review for another 9 days now with no messages or updates. I’ve contacted app review support as well (case ID- 102826632729). I understand review times can vary, but delays like this make it difficult for developers to plan launches or push updates when the review process is the only path to distributing apps. As paying members of the Apple Developer Program, we rely heavily on this pipeline functioning reliably. Hoping this post will reach someone from Apple who can help move the process along. If any other devs have suggestions/tips that have worked for them, please share so others in this position can become unblocked. Thanks in advance.

After I set manual release, The app get approved and changed to Pending for Developer release status. I release the app but stuck in "Processing for distribution" now for 11 days. Please anything I can do to solve this, I edited the promotional text, changed price starting date and more. But nothing. I contact Apple support but still get an answer.